home *** CD-ROM | disk | FTP | other *** search
-
-
-
- CO(1) Programmer's Manual CO(1)
-
-
-
- NAME
- co - check out RCS revisions
-
- SYNOPSIS
- co [_✓o_✓p_✓t_✓i_✓o_✓n_✓s] _✓f_✓i_✓l_✓e ...
-
- DESCRIPTION
- co retrieves a revision from each RCS file and stores it
- into the corresponding working file. Each file name ending
- in ,v is taken to be an RCS file; all other files are
- assumed to be working files. If only a working file is
- given, co tries to find the corresponding RCS file in the
- directory ./RCS and then in the current directory. For more
- details, see FILE NAMING below.
-
- Revisions of an RCS file may be checked out locked or
- unlocked. Locking a revision prevents overlapping updates.
- A revision checked out for reading or processing (e.g., com-
- piling) need not be locked. A revision checked out for
- editing and later checkin must normally be locked. Checkout
- with locking fails if the revision to be checked out is
- currently locked by another user. (A lock may be broken
- with rcs(1).) Checkout with locking also requires the
- caller to be on the access list of the RCS file, unless he
- is the owner of the file or the superuser, or the access
- list is empty. Checkout without locking is not subject to
- accesslist restrictions, and is not affected by the presence
- of locks.
-
- A revision is selected by options for revision or branch
- number, checkin date/time, author, or state. When the
- selection options are applied in combination, co retrieves
- the latest revision that satisfies all of them. If none of
- the selection options is specified, co retrieves the latest
- revision on the default branch (normally the trunk, see the
- -b option of rcs(1)). A revision or branch number may be
- attached to any of the options -f, -I, -l, -p, -q, -r, or
- -u. The options -d (date), -s (state), and -w (author)
- retrieve from a single branch, the _✓s_✓e_✓l_✓e_✓c_✓t_✓e_✓d branch, which is
- either specified by one of -f, ..., -u, or the default
- branch.
-
- A co command applied to an RCS file with no revisions
- creates a zero-length working file. co always performs key-
- word substitution (see below).
-
- OPTIONS
- -r[_✓r_✓e_✓v]
- retrieves the latest revision whose number is less than
- or equal to _✓r_✓e_✓v. If _✓r_✓e_✓v indicates a branch rather than
- a revision, the latest revision on that branch is
- retrieved. If _✓r_✓e_✓v is omitted, the latest revision on
-
-
-
- Printed 1/29/91 1990/12/04 1
-
-
-
-
-
-
- CO(1) Programmer's Manual CO(1)
-
-
-
- the default branch (see the -b option of rcs(1)) is
- retrieved. A revision is composed of one or more
- numeric or symbolic fields separated by periods. The
- numeric equivalent of a symbolic field is specified
- with the -n option of the commands ci(1) and rcs(1).
-
- -l[_✓r_✓e_✓v]
- same as -r, except that it also locks the retrieved
- revision for the caller.
-
- -u[_✓r_✓e_✓v]
- same as -r, except that it unlocks the retrieved revi-
- sion if it was locked by the caller. If _✓r_✓e_✓v is omit-
- ted, -u retrieves the latest revision locked by the
- caller; if no such lock exists, it retrieves the latest
- revision on the default branch.
-
- -f[_✓r_✓e_✓v]
- forces the overwriting of the working file; useful in
- connection with -q. See also FILE MODES below.
-
- -kkv Generate keyword strings using the default form, e.g.
- $Revision: 5.4 $ for the Revision keyword. A locker's
- name is inserted in the value of the Header, Id, and
- Locker keyword strings only as a file is being locked,
- i.e. by ci -l and co -l. This is the default.
-
- -kkvl
- Like -kkv, except that a locker's name is always
- inserted if the given revision is currently locked.
-
- -kk Generate only keyword names in keyword strings; omit
- their values. See KEYWORD SUBSTITUTION below. For
- example, for the Revision keyword, generate the string
- $Revision$ instead of $Revision: 5.4 $. This option is
- useful to ignore differences due to keyword substitu-
- tion when comparing different revisions of a file.
-
- -ko Generate the old keyword string, present in the working
- file just before it was checked in. For example, for
- the Revision keyword, generate the string $Revision:
- 1.1 $ instead of $Revision: 5.4 $ if that is how the
- string appeared when the file was checked in. This can
- be useful for binary file formats that cannot tolerate
- any changes to substrings that happen to take the form
- of keyword strings.
-
- -kv Generate only keyword values for keyword strings. For
- example, for the Revision keyword, generate the string
- 5.4 instead of $Revision: 5.4 $. This can help gen-
- erate files in programming languages where it is hard
- to strip keyword delimiters like $Revision: $ from a
-
-
-
- Printed 1/29/91 1990/12/04 2
-
-
-
-
-
-
- CO(1) Programmer's Manual CO(1)
-
-
-
- string. However, further keyword substitution cannot
- be performed once the keyword names are removed, so
- this option should be used with care. Because of this
- danger of losing keywords, this option cannot be com-
- bined with -l, and the owner write permission of the
- working file is turned off; to edit the file later,
- check it out again without -kv.
-
- -p[_✓r_✓e_✓v]
- prints the retrieved revision on the standard output
- rather than storing it in the working file. This
- option is useful when co is part of a pipe.
-
- -q[_✓r_✓e_✓v]
- quiet mode; diagnostics are not printed.
-
- -I[_✓r_✓e_✓v]
- interactive mode; the user is prompted and questioned
- even if the standard input is not a terminal.
-
- -d_✓d_✓a_✓t_✓e
- retrieves the latest revision on the selected branch
- whose checkin date/time is less than or equal to _✓d_✓a_✓t_✓e.
- The date and time may be given in free format. The
- time zone LT stands for local time; other common time
- zone names are understood. For example, the following
- _✓d_✓a_✓t_✓es are equivalent if local time is January 11, 1990,
- 8pm Pacific Standard Time (eight hours west of GMT):
-
- 8:00 pm lt
- 4:00 AM, Jan. 12, 1990 note: default is GMT
- 1990/01/12 04:00:00 RCS date format
- Thu Jan 11 20:00:00 1990 LT output of ctime(3) + LT
- Thu Jan 11 20:00:00 PST 1990 output of date(1)
- Fri Jan 12 04:00:00 GMT 1990
- Thu, 11 Jan 1990 20:00:00 -0800
- Fri-JST, 1990, 1pm Jan 12
- 12-January-1990, 04:00-WET
-
- Most fields in the date and time may be defaulted. The
- default time zone is GMT. The other defaults are
- determined in the order year, month, day, hour, minute,
- and second (most to least significant). At least one
- of these fields must be provided. For omitted fields
- that are of higher significance than the highest pro-
- vided field, the time zone's current values are
- assumed. For all other omitted fields, the lowest pos-
- sible values are assumed. For example, the date 20,
- 10:30 defaults to 10:30:00 GMT of the 20th of the GMT
- time zone's current month and year. The date/time must
- be quoted if it contains spaces.
-
-
-
-
- Printed 1/29/91 1990/12/04 3
-
-
-
-
-
-
- CO(1) Programmer's Manual CO(1)
-
-
-
- -s_✓s_✓t_✓a_✓t_✓e
- retrieves the latest revision on the selected branch
- whose state is set to _✓s_✓t_✓a_✓t_✓e.
-
- -w[_✓l_✓o_✓g_✓i_✓n]
- retrieves the latest revision on the selected branch
- which was checked in by the user with login name _✓l_✓o_✓g_✓i_✓n.
- If the argument _✓l_✓o_✓g_✓i_✓n is omitted, the caller's login is
- assumed.
-
- -j_✓j_✓o_✓i_✓n_✓l_✓i_✓s_✓t
- generates a new revision which is the join of the revi-
- sions on _✓j_✓o_✓i_✓n_✓l_✓i_✓s_✓t. This option is largely obsoleted by
- rcsmerge(1) but is retained for backwards compatibil-
- ity.
-
- The _✓j_✓o_✓i_✓n_✓l_✓i_✓s_✓t is a comma-separated list of pairs of the
- form _✓r_✓e_✓v_✓2:_✓r_✓e_✓v_✓3, where _✓r_✓e_✓v_✓2 and _✓r_✓e_✓v_✓3 are (symbolic or
- numeric) revision numbers. For the initial such pair,
- _✓r_✓e_✓v_✓1 denotes the revision selected by the above options
- -f, ..., -w. For all other pairs, _✓r_✓e_✓v_✓1 denotes the
- revision generated by the previous pair. (Thus, the
- output of one join becomes the input to the next.)
-
- For each pair, co joins revisions _✓r_✓e_✓v_✓1 and _✓r_✓e_✓v_✓3 with
- respect to _✓r_✓e_✓v_✓2. This means that all changes that
- transform _✓r_✓e_✓v_✓2 into _✓r_✓e_✓v_✓1 are applied to a copy of _✓r_✓e_✓v_✓3.
- This is particularly useful if _✓r_✓e_✓v_✓1 and _✓r_✓e_✓v_✓3 are the
- ends of two branches that have _✓r_✓e_✓v_✓2 as a common ances-
- tor. If _✓r_✓e_✓v_✓1<_✓r_✓e_✓v_✓2<_✓r_✓e_✓v_✓3 on the same branch, joining
- generates a new revision which is like _✓r_✓e_✓v_✓3, but with
- all changes that lead from _✓r_✓e_✓v_✓1 to _✓r_✓e_✓v_✓2 undone. If
- changes from _✓r_✓e_✓v_✓2 to _✓r_✓e_✓v_✓1 overlap with changes from
- _✓r_✓e_✓v_✓2 to _✓r_✓e_✓v_✓3, co prints a warning and includes the
- overlapping sections, delimited by the lines
- <<<<<<< _✓r_✓e_✓v_✓1, =======, and >>>>>>> _✓r_✓e_✓v_✓3.
-
- For the initial pair, _✓r_✓e_✓v_✓2 may be omitted. The default
- is the common ancestor. If any of the arguments indi-
- cate branches, the latest revisions on those branches
- are assumed. The options -l and -u lock or unlock
- _✓r_✓e_✓v_✓1.
-
- -V_✓n Emulate RCS version _✓n, where _✓n may be 3, 4, or 5. This
- may be useful when interchanging RCS files with others
- who are running older versions of RCS. To see which
- version of RCS your correspondents are running, have
- them invoke rlog on an RCS file; if none of the first
- few lines of output contain the string branch: it is
- version 3; if the dates' years have just two digits, it
- is version 4; otherwise, it is version 5. An RCS file
- generated while emulating version 3 will lose its
-
-
-
- Printed 1/29/91 1990/12/04 4
-
-
-
-
-
-
- CO(1) Programmer's Manual CO(1)
-
-
-
- default branch. An RCS revision generated while emu-
- lating version 4 or earlier will have a timestamp that
- is off by up to 13 hours. A revision extracted while
- emulating version 4 or earlier will contain dates of
- the form _✓y_✓y/_✓m_✓m/_✓d_✓d instead of _✓y_✓y_✓y_✓y/_✓m_✓m/_✓d_✓d and may also
- contain different white space in the substitution for
- $Log$.
-
- KEYWORD SUBSTITUTION
- Strings of the form $_✓k_✓e_✓y_✓w_✓o_✓r_✓d$ and $_✓k_✓e_✓y_✓w_✓o_✓r_✓d:...$ embedded in
- the text are replaced with strings of the form
- $_✓k_✓e_✓y_✓w_✓o_✓r_✓d:_✓v_✓a_✓l_✓u_✓e$ where _✓k_✓e_✓y_✓w_✓o_✓r_✓d and _✓v_✓a_✓l_✓u_✓e are pairs listed
- below. Keywords may be embedded in literal strings or com-
- ments to identify a revision.
-
- Initially, the user enters strings of the form $_✓k_✓e_✓y_✓w_✓o_✓r_✓d$.
- On checkout, co replaces these strings with strings of the
- form $_✓k_✓e_✓y_✓w_✓o_✓r_✓d:_✓v_✓a_✓l_✓u_✓e$. If a revision containing strings of
- the latter form is checked back in, the value fields will be
- replaced during the next checkout. Thus, the keyword values
- are automatically updated on checkout. This automatic sub-
- stitution can be modified by the -k options.
-
- Keywords and their corresponding values:
-
- $Author$
- The login name of the user who checked in the revision.
-
- $Date$
- The date and time (GMT) the revision was checked in.
-
- $Header$
- A standard header containing the full pathname of the
- RCS file, the revision number, the date (GMT), the
- author, the state, and the locker (if locked).
-
- $Id$ Same as $Header$, except that the RCS file name is
- without a path.
-
- $Locker$
- The login name of the user who locked the revision
- (empty if not locked).
-
- $Log$
- The log message supplied during checkin, preceded by a
- header containing the RCS file name, the revision
- number, the author, and the date (GMT). Existing log
- messages are _✓n_✓o_✓t replaced. Instead, the new log mes-
- sage is inserted after $Log:...$. This is useful for
- accumulating a complete change log in a source file.
-
- $RCSfile$
-
-
-
- Printed 1/29/91 1990/12/04 5
-
-
-
-
-
-
- CO(1) Programmer's Manual CO(1)
-
-
-
- The name of the RCS file without a path.
-
- $Revision$
- The revision number assigned to the revision.
-
- $Source$
- The full pathname of the RCS file.
-
- $State$
- The state assigned to the revision with the -s option
- of rcs(1) or ci(1).
-
- FILE NAMING
- Pairs of RCS files and working files may be specified in
- three ways (see also the example section).
-
- 1) Both the RCS file and the working file are given. The
- RCS file name is of the form _✓p_✓a_✓t_✓h_✓1/_✓w_✓o_✓r_✓k_✓f_✓i_✓l_✓e,v and the work-
- ing file name is of the form _✓p_✓a_✓t_✓h_✓2/_✓w_✓o_✓r_✓k_✓f_✓i_✓l_✓e where _✓p_✓a_✓t_✓h_✓1/ and
- _✓p_✓a_✓t_✓h_✓2/ are (possibly different or empty) paths and _✓w_✓o_✓r_✓k_✓f_✓i_✓l_✓e
- is a file name.
-
- 2) Only the RCS file is given. Then the working file is
- created in the current directory and its name is derived
- from the name of the RCS file by removing _✓p_✓a_✓t_✓h_✓1/ and the
- suffix ,v.
-
- 3) Only the working file is given. Then co looks for an RCS
- file of the form _✓p_✓a_✓t_✓h_✓2/RCS/_✓w_✓o_✓r_✓k_✓f_✓i_✓l_✓e,v or _✓p_✓a_✓t_✓h_✓2/_✓w_✓o_✓r_✓k_✓f_✓i_✓l_✓e,v
- (in this order).
-
- If the RCS file is specified without a path in 1) and 2),
- then co looks for the RCS file first in the directory ./RCS
- and then in the current directory.
-
- EXAMPLES
- Suppose the current directory contains a subdirectory RCS
- with an RCS file io.c,v. Then all of the following commands
- retrieve the latest revision from RCS/io.c,v and store it
- into io.c.
-
- co io.c; co RCS/io.c,v; co io.c,v;
- co io.c RCS/io.c,v; co io.c io.c,v;
- co RCS/io.c,v io.c; co io.c,v io.c;
-
- FILE MODES
- The working file inherits the read and execute permissions
- from the RCS file. In addition, the owner write permission
- is turned on, unless -kv is set or the file is checked out
- unlocked and locking is set to strict (see rcs(1)).
-
-
-
-
-
- Printed 1/29/91 1990/12/04 6
-
-
-
-
-
-
- CO(1) Programmer's Manual CO(1)
-
-
-
- If a file with the name of the working file exists already
- and has write permission, co aborts the checkout, asking
- beforehand if possible. If the existing working file is not
- writable or -f is given, the working file is deleted without
- asking.
-
- FILES
- co accesses files much as ci(1) does, except that it does
- not need to read the working file.
-
- DIAGNOSTICS
- The RCS file name, the working file name, and the revision
- number retrieved are written to the diagnostic output. The
- exit status is zero if and only if all operations were suc-
- cessful.
-
- IDENTIFICATION
- Author: Walter F. Tichy.
- Revision Number: 5.4; Release Date: 1990/12/04.
- Copyright c 1982, 1988, 1989 by Walter F. Tichy.
- Copyright c 1990 by Paul Eggert.
-
- SEE ALSO
- ci(1), ctime(3), date(1), ident(1), rcs(1), rcsdiff(1),
- rcsintro(1), rcsmerge(1), rlog(1), rcsfile(5)
- Walter F. Tichy, RCS--A System for Version Control,
- _✓S_✓o_✓f_✓t_✓w_✓a_✓r_✓e--_✓P_✓r_✓a_✓c_✓t_✓i_✓c_✓e & _✓E_✓x_✓p_✓e_✓r_✓i_✓e_✓n_✓c_✓e 15, 7 (July 1985), 637-654.
-
- LIMITS
- Links to the RCS and working files are not preserved.
-
- There is no way to selectively suppress the expansion of
- keywords, except by writing them differently. In nroff and
- troff, this is done by embedding the null-character \& into
- the keyword.
-
- BUGS
- The -d option sometimes gets confused, and accepts no date
- before 1970.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Printed 1/29/91 1990/12/04 7
-
-
-
-